reapTimedOutRunners skipped runners in pending_delete/pending_force_delete/
deleting/deleted status, but not creating/pending_create. When a runner's
scale-set-level bootstrap timeout elapsed while its instance was still
being created in the provider (e.g. CloudStack deploy running long due to
host iowait) and it had never joined github, this tried to transition the
instance straight from creating to pending_delete. That transition isn't
allowed (InstanceCreating only permits -> error or -> running), so
UpdateInstance returned a BadRequestError.

That error was treated as fatal: reapTimedOutRunners immediately unlocked
everything it had processed so far and returned early, and its caller
(consolidateRunnerState) aborted the rest of consolidation for that scale
set on any error. This meant a single runner still legitimately booting
(just slow) could block reaping of every other eligible runner in the same
scale set, repeating every consolidate tick (~5 min) until the poisoned
runner resolved on its own via the provider worker's separate create-
timeout handling. Observed in prod: 'invalid instance status transition
from creating to pending_delete' logged repeatedly for the micro scale set
while CloudStack was slow due to iowait.

Fix:
  * Skip InstanceCreating/InstancePendingCreate in reapTimedOutRunners,
    mirroring the same skip already done later in consolidateRunnerState.
    The provider worker owns create timeouts/failures for these instances.
  * Don't let one runner's transition error abort the whole batch: log it,
    release just that runner's lock, and keep processing the rest instead
    of returning early.